packages/table-devtools/src/components/FeaturesPanel.tsx (1)

193-193: Remove the now-dead row-count helpers in the same pass.

This render path no longer consumes ROW_MODEL_TO_GETTER / getRowCountForModel, so those declarations are now just stale maintenance surface. I'd drop them here to keep the panel implementation aligned with what it actually renders.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/table-devtools/src/components/FeaturesPanel.tsx` at line 193, The
ROW_MODEL_TO_GETTER mapping and getRowCountForModel helper are now unused by the
FeaturesPanel render path (the UI only references rowModelName), so remove those
dead declarations to reduce maintenance surface; locate and delete the
ROW_MODEL_TO_GETTER constant and the getRowCountForModel function (and any
nearby unused imports/exports that only served them) so the panel code only
contains live symbols referenced by FeaturesPanel (e.g., the rowModelName
rendering logic).

packages/table-devtools/src/components/OptionsPanel.tsx (2)

11-17: Conditional useStore may not react to late table availability.

In Solid.js, the component body runs once at creation. If table() initially returns undefined and later becomes available, useStore is never called because the ternary was already evaluated. Consider using createMemo or restructuring to ensure reactivity:

♻️ Suggested refactor using Show or createMemo

+import { Show, createMemo } from 'solid-js'
+
 export function OptionsPanel() {
   const styles = useStyles()
   const { table } = useTableDevtoolsContext()
 
-  const tableInstance = table()
-  const tableState = tableInstance
-    ? useStore(
-        tableInstance.optionsStore,
-        ({ state, data, _features, _rowModels, ...options }) => options,
-      )
-    : undefined
+  return (
+    <div class={styles().panelScroll}>
+      <Show when={table()} fallback={<div>No table available</div>}>
+        {(tableInstance) => {
+          const tableState = useStore(
+            tableInstance().optionsStore,
+            ({ state, data, _features, _rowModels, ...options }) => options,
+          )
+          return (
+            <ResizableSplit
+              left={
+                <>
+                  <div class={styles().sectionTitle}>Options</div>
+                  <JsonTree copyable value={tableState()} />
+                </>
+              }
+              right={<></>}
+            />
+          )
+        }}
+      </Show>
+    </div>
+  )
+}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/table-devtools/src/components/OptionsPanel.tsx` around lines 11 -
17, The current ternary that calls useStore with tableInstance (table(),
tableInstance, useStore, tableInstance.optionsStore) runs only once and will
miss when table() is undefined at mount and later becomes available; refactor so
useStore is invoked reactively — e.g., wrap access to table() in a createMemo or
guard with a Solid <Show> so that when table() becomes non-undefined you call
useStore(tableInstance.optionsStore, ...) and update tableState accordingly;
ensure you reference the same selector ({ state, data, _features, _rowModels,
...options }) and return undefined until the table exists to preserve types and
reactivity.

---

19-25: Redundant tableState?.() call on line 20.

The first invocation is discarded. If intended for reactivity tracking, it wouldn't work here since getState isn't wrapped in a reactive primitive. Simplify by removing it:

🧹 Simplified getState

   const getState = (): unknown => {
-    tableState?.()
     if (!tableInstance) {
       return undefined
     }
     return tableState?.()
   }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/table-devtools/src/components/OptionsPanel.tsx` around lines 19 -
25, The getState function contains a redundant initial call to tableState
(tableState?.()) whose return value is discarded; remove that first invocation
and simplify getState to only check tableInstance and then return tableState?.()
so the function either returns undefined when tableInstance is falsy or the
result of tableState; if the original intent was to trigger reactivity, wrap
getState in the appropriate reactive primitive instead of relying on a discarded
call.

packages/solid-table-devtools/vite.config.ts (1)

6-15: Consider adding server.allowedHosts for CodeSandbox compatibility.

For consistency with other Vite configs in the repository and forward compatibility with newer Vite versions, consider adding DNS rebinding protection:

 const config = defineConfig({
   plugins: [solid()],
+  server: { allowedHosts: true },
   test: {
     name: packageJson.name,

This is optional for a package build config but ensures compatibility if the dev server is used during development. Based on learnings: "add server: { allowedHosts: true } to enable DNS rebinding protection in CodeSandbox environments when using newer Vite versions."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/solid-table-devtools/vite.config.ts` around lines 6 - 15, The Vite
config defined by the const config = defineConfig(...) is missing
server.allowedHosts which can block CodeSandbox/dev-server DNS rebinding; update
the defineConfig call to include a server property with allowedHosts: true
(e.g., add server: { allowedHosts: true }) so the dev server in this package
(solid-table-devtools) matches other repo configs and remains compatible with
newer Vite versions and CodeSandbox environments.

packages/solid-table-devtools/src/TableDevtools.tsx (1)

20-23: Consider wrapping setTableDevtoolsTarget in an effect for reactive updates.

setTableDevtoolsTarget(props.table) is called during component execution. While Solid components run once (unlike React), if props.table is intended to be reactive (e.g., swapped dynamically), this won't re-execute when the table changes.

♻️ Suggested refactor using createEffect

+import { createEffect } from 'solid-js'
 import { createSolidPanel } from '@tanstack/devtools-utils/solid'
 import {
   TableDevtoolsCore,
   setTableDevtoolsTarget,
 } from '@tanstack/table-devtools'

 function TableDevtoolsPanel(props: TableDevtoolsSolidInit) {
-  setTableDevtoolsTarget(props.table)
+  createEffect(() => {
+    setTableDevtoolsTarget(props.table)
+  })
   return <TableDevtoolsPanelBase theme={props.theme} />
 }

If the table instance is expected to remain static for the lifetime of the component, the current implementation is fine. Please confirm the intended usage pattern.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/solid-table-devtools/src/TableDevtools.tsx` around lines 20 - 23,
The call to setTableDevtoolsTarget inside TableDevtoolsPanel should be moved
into a Solid reactive effect so updates to props.table propagate; in
TableDevtoolsPanel wrap setTableDevtoolsTarget(props.table) in createEffect
(import createEffect from 'solid-js') so when props.table changes the target is
updated, leaving the component to return <TableDevtoolsPanelBase
theme={props.theme} /> as before; keep the original static-path behavior if you
intend the table to never change, otherwise use createEffect around the
setTableDevtoolsTarget call.

packages/react-table/src/useTable.ts (1)

21-22: Unused useIsomorphicLayoutEffect definition.

useIsomorphicLayoutEffect is defined but never used in this file. The previous usage appears to have been removed as part of this refactor. Consider removing this dead code.

🧹 Proposed fix to remove unused code

-const useIsomorphicLayoutEffect =
-  typeof window !== 'undefined' ? useLayoutEffect : useEffect

And update the import:

-import { useEffect, useLayoutEffect, useMemo, useState } from 'react'
+import { useEffect, useMemo, useState } from 'react'

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/react-table/src/useTable.ts` around lines 21 - 22, Remove the unused
constant useIsomorphicLayoutEffect and any now-unnecessary imports: delete the
line defining useIsomorphicLayoutEffect (the conditional assignment using
useLayoutEffect and useEffect) and then remove useLayoutEffect and/or useEffect
from the import list in this module if they are no longer used elsewhere in
useTable.ts; ensure no other code references useIsomorphicLayoutEffect after the
removal.

packages/table-core/src/core/table/constructTable.ts (2)

63-69: Verify the double .state access is intentional.

The expression table.optionsStore.state.state accesses:

1. optionsStore.state → the stored TableOptions
2. .state → the options.state property (user-provided partial state overrides)

This appears correct for overlaying user-provided state onto the base store state, but the double .state could be confusing. Consider adding a clarifying comment.

   table.store = createStore(() => {
     const state = table.baseStore.state
     return {
       ...state,
+      // Overlay user-provided state from options.state onto the base state
       ...(table.optionsStore.state.state ?? {}),
     }
   })

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/table-core/src/core/table/constructTable.ts` around lines 63 - 69,
The double .state access in constructTable when assigning table.store (inside
the createStore callback) is intentional: it overlays the user-provided partial
state found at table.optionsStore.state.state onto the base state; add a brief
clarifying comment above that line explaining that table.optionsStore.state is
the TableOptions object and its .state property contains user overrides, e.g.,
“// overlay user-provided partial state from optionsStore.state.state onto base
state”, so future readers of createStore / table.store and references to
table.optionsStore.state.state are not confused.

---

37-42: Consider aligning the setter behavior with setOptions.

The options setter directly replaces the entire state, while table.setOptions performs merging via table_mergeOptions. This inconsistency could lead to unexpected behavior if someone uses table.options = newOptions expecting the same merge semantics as setOptions.

Consider either:

1. Making the setter call setOptions internally for consistency
2. Documenting this as a "replace-all" operation distinct from setOptions

♻️ Option 1: Align setter with setOptions merge behavior

     get options() {
       return this.optionsStore.state
     },
     set options(value) {
-      this.optionsStore.setState(() => value)
+      this.setOptions(() => value)
     },

Note: This requires setOptions to be available, which it isn't at construction time. An alternative is to simply remove the setter to enforce using setOptions.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/table-core/src/core/table/constructTable.ts` around lines 37 - 42,
The options setter currently replaces state via this.optionsStore.setState and
diverges from table.setOptions which merges using table_mergeOptions; remove the
options setter (leave only the getter) so callers must use setOptions (which
uses table_mergeOptions), or alternatively replace the setter body to delegate
to this.setOptions(value) if you can guarantee setOptions is available; update
references to the options setter accordingly to enforce consistent merge
semantics.

packages/angular-table/src/injectTable.ts (1)

119-124: Commented-out optionsNotifier binding.

The optionsNotifier is commented out. If this is intentional (options reactivity handled differently in Angular), consider removing the comment to avoid confusion. If it's meant to be implemented, this should be tracked.

     const angularReactivityFeature = constructReactivityFeature({
-      // optionsNotifier: () => stateNotifier(),
       stateNotifier: () => {
         return stateNotifier()
       },
     })

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/angular-table/src/injectTable.ts` around lines 119 - 124, The
commented-out optionsNotifier line in the constructReactivityFeature call (the
optionsNotifier property next to stateNotifier inside the
angularReactivityFeature instantiation) is ambiguous; either remove the
commented line to avoid confusion or implement/enable it if options reactivity
is required. Update the constructReactivityFeature call by either deleting the
commented-out "optionsNotifier: () => stateNotifier()," line or by providing a
proper optionsNotifier implementation (e.g., optionsNotifier: () =>
optionsNotifier() or wiring to the correct notifier) alongside the existing
stateNotifier to ensure options reactivity is explicit.

packages/table-core/src/features/table-reactivity/tableReactivityFeature.ts (1)

5-8: Empty interface flagged by static analysis.

The TableReactivityFeatureConstructors interface is empty, which Biome flags as equivalent to {}. If this is a placeholder for future extension, consider adding a comment. Otherwise, a type alias would be cleaner.

♻️ Options to address empty interface

Option 1 - Add explanatory comment:

+// Placeholder for future constructors - intentionally empty for now
 interface TableReactivityFeatureConstructors<
   TFeatures extends TableFeatures,
   TData extends RowData,
 > {}

Option 2 - Use type alias:

-interface TableReactivityFeatureConstructors<
-  TFeatures extends TableFeatures,
-  TData extends RowData,
-> {}
+type TableReactivityFeatureConstructors<
+  TFeatures extends TableFeatures,
+  TData extends RowData,
+> = Record<string, never>

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/table-core/src/features/table-reactivity/tableReactivityFeature.ts`
around lines 5 - 8, The interface TableReactivityFeatureConstructors is empty
(equivalent to {}), so replace it with a clearer construct: either add an
explanatory comment above TableReactivityFeatureConstructors stating it’s
intentionally empty as a future extension point, or convert it to a type alias
(e.g. type TableReactivityFeatureConstructors<TFeatures extends TableFeatures,
TData extends RowData> = {}) to avoid the empty-interface lint; update any
references to the symbol accordingly and ensure generics (TFeatures, TData)
remain declared on the alias if you choose that option.

packages/solid-table/src/createTable.ts (1)

70-74: Type assertion to any loses type safety.

The as any cast on mergedOptions bypasses TypeScript's type checking. Consider using a more specific type assertion or restructuring to maintain type safety.

-  const mergedOptions = mergeProps(tableOptions, {
-    _features: mergeProps(tableOptions._features, {
-      solidReactivityFeature,
-    }),
-  }) as any
+  const mergedOptions = mergeProps(tableOptions, {
+    _features: mergeProps(tableOptions._features ?? {}, {
+      solidReactivityFeature,
+    }),
+  }) as TableOptions<TFeatures, TData>

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/solid-table/src/createTable.ts` around lines 70 - 74, The current
`mergedOptions` uses `as any`, losing type safety—replace the `as any` cast by
preserving/declaring the concrete type: either call `mergeProps` with
appropriate generics or explicitly type `mergedOptions` to the correct options
interface (e.g., the TableOptions type used by `createTable`) and ensure the
`_features` shape includes `solidReactivityFeature`; update the
`mergeProps(tableOptions, {...})` invocation to return the typed result (or wrap
the inner merge `mergeProps(tableOptions._features, {...})` with the correct
feature type) so `mergedOptions` has a precise inferred type instead of `any`.

packages/solid-table/src/createTable.ts (1)

73-83: Minor type inconsistency in mergeOptions signature.

The options parameter at line 77 is typed as TableOptions<TFeatures, TData>, but the core type definition expects Partial<TableOptions<TFeatures, TData>>. This won't cause runtime issues but creates a type mismatch with the interface contract.

🔧 Suggested fix

       mergeOptions: (
         defaultOptions: TableOptions<TFeatures, TData>,
-        options: TableOptions<TFeatures, TData>,
+        options: Partial<TableOptions<TFeatures, TData>>,
       ) => {
         return mergeProps(defaultOptions, options)
       },

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/solid-table/src/createTable.ts` around lines 73 - 83, The
mergeOptions callback in createTable (the inline function assigned to
resolvedOptions.mergeOptions) has its second parameter typed as
TableOptions<TFeatures, TData> but should be Partial<TableOptions<TFeatures,
TData>> to match the expected interface; update the signature of the options
parameter in that mergeOptions function to Partial<TableOptions<TFeatures,
TData>> (keeping the return as mergeProps(defaultOptions, options)) so the types
align with the core type definition.